Folks,

TL/DR: This shouldn't be published, possibly ever, certainly not in
its current state.

I remain bewildered as to what this specification offers above and
beyond XEP-0060, and I cannot implement from this specification.

This is, in part, because the document is written in essentially two
parts - one describes how good it'll be once you've got it, and the
other has some very lightweight sketches of what the protocol might
look like if it were specified, and most of those appear to be
reinventions of existing XMPP protocol extensions.

An example is registration. The authors have elected to write their
own registration protocol, rather than use XEP-0077. Perhaps this is
needed, but it's not clear because the behaviour of a Controller when
given a registration request isn't specified. I have no idea what a
Controller is meant to do with the registration. Maybe register. But
if I don't, does it work anyway? Who knows. It's in an XML namespace
which appears to be, at best non-traditional, at worst illegal. The
register element, despite being empty, is spelt out "in full" with
both opening and closing tags, which seems odd - perhaps the
serializer used does this and it's a cut and paste.

Then there's a "login" and "logout". A "login" looks reasonable modulo
the horrible use of incorrect XML namespacing, though again I have
absolutely no idea what it might do, and what the requirement is here.
The login result, on the other hand, is special - it's placed in the
default namespace (ie, xmlns=""), which really should not be used. It
contains a <value/> element, with a default-namespaced attribute. I
didn't even know that was legal, so I'm impressed. The meaning of
<value/>, and whether xsi:nil can also be set to "false", is not
explained. Perhaps that's obvious.

Typically, in XMPP, we have used presence to indicate client
availability - but without knowing whether this is what's intended
with the login/logout construct, I have no idea if that meets the
requirements - it's only mentioned in passing in §2.4.

The "getCapabilityListRequest", which is also in the default
namespace, is another example of reinventing a perfectly serviceable
wheel. XEP-0030 includes a full suite of discovery, and for that
matter the XMPP community has been using "versioned" namespaces to
offer parallel revisions of services for many years, with much
success.

In this entirely new capability discovery, however, the response
includes a set of triples of "id", "name", and "version". None of
these are explained. The example contains a lengthy list of
capabilities, none of which seem to be documented anywhere.

Next up - sorry, there's nothing so simple as section numbers here -
there's DiscoveryQuery, which looks suspiciously like it might be a
rendition of Java introspection over XMPP. It says it responds with a
hostname; it doesn't, instead it responds with a Jid. Again, this kind
of discovery is supported within XEP-0030 - it's a disco#items
request, so not search-based, but the functionality is there
nonetheless, and certainly doesn't need rewriting from scratch.

Publisher registration is, I think, new - XEP-0060 does not have
anything similar that I can immediately think of.

Subscription, on the other hand, is very much within XEP-0060. I have
literally no idea why this isn't used.

Publishing actually does, here, use XEP-0060 - though no mention of
the fact is made, and there's no documentation of the payload format.

The security considerations section seems mostly OK, but please note
that §5.3.1 suddenly decides to replace the transport layer with HTTP,
which is mildly confusing to say the least. How we're supposed to
authenticate over XMPP using an HTTP authentication mechanism is
unknown.

So what we have here is a vast amount of NIH, plus - if my
understanding is correct - one added feature, that'd make a two-page
XEP.

This is *not* to say that XMPP has no place in CTI sharing; in fact I
think it's very useful. But by departing from existing, well-defined
XMPP protocol extensions, this specification promptly loses many
advantages. As an example, while XEP-0060 provides a reasonably
complete pubsub service on its own, it can be enhanced by XEP-0314
into permitting originator-controlled data labelling, which in turn
can be used for access control, highly useful in federated
environments. Instead of poorly describing a new protocol extension
which duplicates existing work, it'd be much better if the document
described how to use existing protocol effectively - and indeed, where
the document is doing so, it works well.

Dave.
(Personal opinion, not as XMPP Council or XMPP Standards Foundation).

On 31 March 2017 at 04:50, Takeshi Takahashi
<takeshi_takahashi@nict.go.jp> wrote:
> Hello all,
>
> This is a WGLC for draft-ietf-mile-xmpp-grid.
> The version to be reviewed is
> https://tools.ietf.org/id/draft-ietf-mile-xmpp-grid-02.txt
>
> We will have 1 month for this call.
> Please provide comments before May 1st and provide your support and/ or
> raise any issue you feel are yet to be addressed.
>
> Thank you.
> Take
>
>
> _______________________________________________
> mile mailing list
> mile@ietf.org
> https://www.ietf.org/mailman/listinfo/mile